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Abstract 


This memo defines an interim solution for Infrastructure ENUM in 
order to allow a combined User and Infrastructure ENUM implementation 
in el64.arpa as a national choice. This interim solution will be 
deprecated after implementation of the long-term solution. 
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1. Introduction 


ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms 
E.164 numbers [E164] into domain names and then queries the DNS 
(Domain Name Service) [RFC1034] for NAPTR (Naming Authority Pointer) 
records [RFC3401] in order to look up which services are available 
for a specific domain name. 


ENUM, as defined in RFC 3761 (User ENUM), is not well suited for the 
purpose of interconnection by carriers and voice-service providers, 
as can be seen by the use of various private tree arrangements based 
on ENUM mechanisms. 


Infrastructure ENUM is defined as the use of the technology in RFC 
3761 [RFC3761] by the carrier-of-record (voice service provider) 
[RFC5067] for a specific E.164 number [E164] in order to publish a 
mapping of this telephone number to one or more Uniform Resource 
Identifiers (URIs) [RFC3986]. 


Other voice service providers can query the DNS for this mapping and 
use the resulting URIs as input into their call-routing algorithm. 

These URIs are separate from any URIs that the end-user who registers 
an E.164 number in ENUM may wish to associate with that E.164 number. 


The requirements, terms, and definitions for Infrastructure ENUM are 
defined in [RFC5067]. 


Using the same E.164 number to domain mapping techniques for other 
applications under a different, internationally agreed-upon apex 
(instead of el64.arpa) is straightforward on the technical side. 
This process of defining the Dynamic Delegation Discovery System 
(DDDS) [RFC3401] application for Infrastructure ENUM is defined in 
[RFC5526]. This is the long-term solution. 
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This document presents an interim solution for Infrastructure ENUM 
and a mechanism for transitioning to the long-term solution. The 
interim solution is based on establishing a branch in the e164.arpa 
tree, which resolvers may locate by following the algorithm described 
in Section 4. The location of the branch is dependent upon country- 
code length, and thus resolvers must determine the position of the 
branch based on the method described in Section 5. Finally, 

Section 6 provides a way that implementations following the 
procedures of Sections 4 and 5 may be seamlessly redirected to the 
long-term solution, when it becomes available. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


3. Interim Solution 


The agreements to establish the long-term solution may take some 
time. It was therefore decided to develop an interim solution that 
can be used by individual countries to implement an interoperable 
Infrastructure ENUM tree immediately. The interim solution will be 
deprecated when the long-term solution [RFC5526] is deployed. It is 
therefore also required that the interim solution includes a smooth 
migration path to the long-term solution. 


It is also required that existing ENUM clients querying User ENUM as 
defined in RFC 3761 [RFC3761] continue to work without any 
modification. 


Because of various reasons (e.g., potentially different delegation 
points, different reliability requirements, and use of DNS 
wildcards), sharing a single domain name between the user itself and 


the respective carrier for a given number is not possible. Hence, a 
different domain name must be used to store infrastructure ENUM 
information. 


In order to avoid the delays associated with the long-term solution, 
the existing delegations and agreements around el64.arpa need to be 
leveraged. 


The method most easily fulfilling the requirements is to branch off 
the el64.arpa tree into a subdomain at the country-code delegation 
level below el64.arpa and deploy an Infrastructure ENUM subtree 
underneath, without touching User ENUM semantics at all. 
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This allows countries using a dedicated country code to introduce the 
interim solution as a national matter to the concerned National 
Regulation Authority (NRA). The governing body of a shared country 
code and the owner of a global network code can also choose to 
implement this solution within their area of responsibility. 


Under this approach, ITU-T (International Telecommunication Union / 
Telecommunication Standardization Sector), IETF, and IAB involvement 
is only lightweight, e.g., to recommend the proper algorithm defined 
here to enable international interoperability. 

4. The Algorithm 
RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS) 
application according to RFC 3401 [RFC3401]. As such, ENUM defines 
the following components of the DDDS algorithm: 
1. Application Unique String 
2. First Well-Known Rule 
3. Expected Output 


4. Valid Databases 


The "Valid Databases" part contains the transformation of an E.164 
telephone number into a domain name. Section 2.4 of RFC 3761 uses 
the following 4-step algorithm for this: 

1. Remove all characters with the exception of the digits. 

2. Put dots (".") between each digit. 

3. Reverse the order of the digits. 


4. Append the string ".el64.arpa" to the end. 


The interim solution for Infrastructure ENUM uses a modified version 
of this algorithm: 


1. Determine the proper POSITION parameter for this E.164 number 
according to the algorithm in Section 5 of this document. 


2. Build an ordered list of single-digit strings from all digits 


appearing in the telephone number. All non-digit characters are 
ignored. 


Haberler, et al. Informational [Page 4] 


RFC 5527 Combined User and Infrastructure ENUM May 2009 


3. Insert a string consisting of "i" into this list, after POSITION 
strings. If the list of strings was shorter than POSITION 
elements, then report an error. 


4. Reverse the order of the list. 
5. Append the string "el64.arpa" to the end of the list. 


6. Create a single domain name by joining the list together with 
dots (".") between each string. 


This is the only point where the interim Infrastructure ENUM (I-ENUM) 
solution differs from straight RFC 3761 ENUM. All other parts of 
User ENUM, including the enumservices registrations, apply to I-ENUM 
as well. 


5. Determining the Position of the Branch 


In order to allow for the deployment of this interim solution 
independent of IAB/ITU-T/RIPE-NCC negotiations, the branching label 
"i" cannot be inserted in the Tier-0 zone (i.e., the el64.arpa zone 
itself) currently managed by RIPE NCC. This condition acts as a 
lower bound on the choice of the POSITION parameter. 


For international E.164-numbers for geographic areas (Section 6.2.1 
of [E164]) and for international E.164-numbers for global services 

(Section 6.2.2 of [E164]), the most sensible choice for POSITION is 
the number of digits in the country code of the number in question. 
This places the branch directly under the country-code level within 
the el64.arpa ENUM tree. 


For international E.164-number for networks (Section 6.2.3 of 
[E164]), the appropriate choice for POSITION is the combined length 
of the CC (Country Code) and IC (Identification Code) fields. 


For international E.164-number for groups of countries (Section 6.2.4 
of [E164]), the value for POSITION is 4. 


The authoritative source for up-to-date country code and network 
Identification Code allocations is published by the ITU-T as a 
complement to the recommendation E.164 [E164]. The current version 
of this complement is available from the ITU website under "ITU-T / 
Service Publications". 


Please note that country code 1 of the North American Numbering Plan 
(NANP) does not fall under the ITU classification of "groups of 
countries", but is a "shared country code" for a geographic area. 
Thus, the POSITION parameter for the NANP is 1. 


Haberler, et al. Informational [Page 5] 


RFC 5527 Combined User and Infrastructure ENUM May 2009 


As of 2007, the POSITION value for a specific E.164 number can be 
determined with the following algorithm: 


o If the number starts with 1 or 7, then POSITION is 1. 


o If the number is in one of the following 2-digit country codes, 
then POSITION is 2: 20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58, 
60-66, 81, 82, 84, 86, 90-95, or 98. 


o If the number starts with 388 or 881, then POSITION is 4. 
o If the number starts with 878 or 882, then POSITION is 5. 


o If the number starts with 883 and the next digit is < 5, then 
POSITION is 6. 


o If the number starts with 883 and the next digit is >= 5, then 
POSITION is 7. 


o In all other cases, POSITION is 3. 


Given the fact that the ITU-T recently allocated only 3-digit country 
codes, there are no more spare 1- and 2-digit country codes and 
existing 1- and 2-digit country codes are extremely unlikely to be 
recovered, the above list of existing 1- and 2-digit country codes 
can be considered very stable. The only problem may be for a country 
that has split, as happened recently, for example, to Yugoslavia. 


Regarding network codes, up to 2007, the ITU-T has only allocated 1- 
and 2-digit ICs. Assignments of 3- and 4-digit ICs started in May 
2007 in the +883 country code. Any further change in the ITU-T 
policy in this respect will need to be reflected in the above 
algorithm. 


6. Transition to the Long-Term Solution 
The proposed long-term solution for Infrastructure ENUM [RFC5526] is 


the establishment of a new zone apex for that tree. This apex will 
play the same role as "el64.arpa" does for User ENUM. 


It is unrealistic to assume that all countries and all ENUM clients 
will manage to migrate from the interim solution to the long-term 
solution at a single point in time. It is thus necessary to plan for 
an incremental transition. 


In order to achieve this, clients using the interim solution need to 


be redirected to the long-term I-ENUM tree for all country codes that 
have already switched to the long-term solution. This SHOULD be done 
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by placing DNAME [RFC2672] records at the branch (the "i") label 
pointing to the appropriate domain name in the long-term I-ENUM tree. 
All descendants at that branch label location where the DNAME record 
is inserted MUST be removed, as required by Section 3 of RFC 2672. 


Therefore, ALL entities involved in making or answering DNS queries 
for I-ENUM MUST fully support the DNAME record type and its 
semantics. In particular, entities involved in I-ENUM lookups MUST 
correctly handle responses containing synthesized CNAMEs that may be 
generated as a consequence of DNAME processing by any other element 
in resolution, typically an iterative mode resolving name server. 


These entities MUST also apply adequate measures to detect loops and 
prevent non-terminating resolutions because of improperly configured 
DNAME records or combinations of DNAME and CNAME records. 


Note: Some caching name server implementations are known to handle 
DNAMEs incorrectly. In the worst case, such bugs could stay 
undetected until a country transitions to the long-term solution. 
Therefore, ensuring full DNAME support from the start (and carefully 
testing that it actually works) is important. 


The domain name for the branch location and its DNAME record SHOULD 
be removed once the transition to the long-term solution is completed 
and all entities involved in I-ENUM have migrated to the new zone 
apex for I-ENUM. 


7. Examples 


These are two examples of how E.164 numbers translate to 
Infrastructure ENUM domains according to the interim solution. 


+1 21255501234 


4. .1.e164.arpa 
+44 2079460123 3 


Se Zico One i 
2d. 0 2684 4.4.e164.arpa 


ere) 
EI 


BEE KERLE 
04228. 
Here is the list of the intermediate steps for the second example to 
visualize how the algorithm defined in Section 4 operates on "+44 
2079460123": 


1. "+44 2079460123" is within a 2-digit country code; thus, POSITION 
iS. .2'. 


2. The list of strings is 
CAMS MAM NO ON METAL, EYE, A, MOM TO ET ow EZ) 


3. POSITION is 2; thus, "i" is inserted between the second and the 


third string, yielding: 
(A EAN ATEM EDEN IE AST EOD EAU NG MUONS NET ot Det ZA AD 
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4. Reversing the list gives: 
aan eee eee SEA ep AUDI NE TEN SAN pa) 


5. Appending "el64.arpa" yields: 
(™3"5 MQM, aa R "OM, NS; "A", MOMs MEN "OM; MOM, a MAN; MAN, "el64.arpa") 


6. Concatenation with dots yields: 
"3.2.1.0.6.4.9.7.0.2.1.4.4.e164.arpa" 


After the introduction of the long-term Infrastructure ENUM solution, 
using, for example, "ienum.example.net" as the new apex for I-ENUM, 
the administrators of +44 can implement a smooth transition by 
putting the following DNAME record in their zone: 


i.4.4.el64.arpa. IN DNAM 


Gl 


4.4.ienum.example.net. 


This way, clients using the interim I-ENUM solution end up querying 
the same tree as clients implementing the long-term solution. 


8. Security Considerations 


Privacy issues have been raised regarding the unwarranted disclosure 
of user information that would result from publishing Infrastructure 


ENUM information in the public DNS. For instance, such disclosure 
could be used for harvesting numbers in service or obtaining unlisted 
numbers. 


Given that number-range allocation is public information, we believe 
the easiest way to cope with such concerns is to fully unroll 
allocated number ranges in the Infrastructure ENUM subtree, wherever 
such privacy concerns exist. Whether or not a number is served would 
be exposed by the carrier-of-record when an attempt is made to 
contact the corresponding URI. We assume this to be an authenticated 
operation, which would not leak information to unauthorized parties. 


Entering all numbers in an allocated number range, whether serviced 
or not, or whether listed or unlisted, will prevent mining attempts 
for such number attributes. 


The result will be that the information in the public DNS will mirror 
number-range allocation information, but no more. Infrastructure 
ENUM will not tell you more than you can get by just dialing numbers. 


The URI pointing to the destination network of the carrier-of-record 
should also not disclose any privacy information about the identity 
of the end-user. It is therefore recommended to use either 
anonymized UserIDs or the E.164 number itself in the user part of the 
URI, such as in sip:+441632960084@example.com. 
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